Name a song's sections automatically, when the user asks for it - #486

…ental twice

Three things about the sections bar, all reported from looking at it.

A Clear button sits beside Add, hidden entirely while there is nothing to
clear. Clearing cannot be undone and an automatic set costs a whole re-import
to regenerate, so the first click only arms the button and the second one
clears; it disarms itself after four seconds. The app has no modal-confirm
idiom anywhere, and this is the lightest guard that still makes a mis-click
harmless.

The header laid its controls out with space-between, so every direct child
drifted to its own corner and Clear ended up marooned from Add. They are one
group now, and the split is title against controls rather than control against
control.

The "Experimental - drag to adjust." badge is gone, along with the
_sectionsSource state that existed only to drive it. How a set arrived is still
recorded server-side; the timeline just no longer labels it, because a marker
is editable either way. The word now sits under the Song structure toggle
instead, where the choice is actually made rather than on the results after the
fact.

While the toggle was being touched: it takes the same width and height as Split
stems, so the pair reads as two segments of one bar rather than a chip loose
beside a button. The width is shared through a variable and set as a minimum,
not a fixed size, so a longer translation grows instead of clipping. It keeps
the timeline blue rather than the accent amber, because two amber controls side
by side read as two competing primary actions.

Repeated section kinds are numbered. The model predicts boundaries and labels
with separate heads, so two neighbouring Verse spans are a real predicted
boundary between verse one and verse two rather than a duplicate, and merging
them was already tried and found to discard five true boundaries on the
reference track. The boundary stays and the labels read Chorus 1 and Chorus 2.
A kind used once is never numbered, and a section renamed by hand keeps its own
name.

Reworking the badge tests into Clear-visibility tests caught a real bug: Clear
lives in the header rather than the ribbon, so its state has to be refreshed
before the container guard in initSections, and it was not.

Exporting a mixdown of a long track as WAV failed with a 500, after the server
had already spent the whole render producing it. The threshold is about 49.5
minutes at 44.1 kHz and 45.5 at 48 kHz, both inside the 60 minutes StemDeck
accepts, so this was a supported track failing rather than an unsupported one
being refused.

_render_to_file finishes by moving the render into the mixdown cache, pruning
the cache, and returning the path the response is built from. The prune evicts
oldest-first while the directory is over budget, and a single render larger
than the whole 500 MB budget puts it over on its own. So the loop deleted the
render, newest and only entry though it was, and FileResponse was handed a path
that no longer existed.

The prune now takes the file about to be served and never evicts it. Its size
still counts toward the total, so an oversized entry clears everything else and
then stops, leaving the cache one file over budget until the next render. That
is the intended trade: a render the user is waiting on outranks the budget.

Reproduced by shrinking the budget below one render, which is the same shape as
a 60-minute WAV against the real 500 MB. The regression test asserts both
halves, because exempting the served file must not quietly turn the prune into
a no-op.

The streaming path prunes too, but the client already has the bytes by then, so
there the same eviction only costs a cache entry rather than the response.

Closes #482

Section analysis stages its work in a temporary directory inside the job's own
stems folder and removes it in a finally. That covers every ordinary ending,
cancellation included. It does not cover the process dying: a force quit, a
lost machine, an OOM kill, or the desktop shell tearing the backend down while
the stage runs. Nothing else in the codebase had ever heard of the prefix, so
what was left behind stayed forever.

It is not a trivial amount. other.wav inside it is a real file, the
other/guitar/piano mix written as pcm_f32le: roughly 1.27 GB for a 60-minute
track, plus the extracted spectrograms beside it. The name starts with a dot,
so a user wondering why their library outgrew their songs had no obvious way to
find it. The window is not small either, because the stage is a CPU inference
pass measured in minutes and it is the last thing a job does, which is exactly
when an impatient user quits.

The sweep runs once at startup and nowhere else. Nothing is analyzing at that
point, so every workspace it finds is certainly dead; running it later could
delete one out from under a live job. It reuses the same guard as the in-band
cleanup, refusing to remove anything whose name lacks the prefix or whose
parent is not the stems directory, because it is deleting inside the user's
library. Its failures are swallowed and logged for the same reason the stage
itself is non-fatal: tidying up must never be the thing that breaks a
separation.

Closes #483

A PATCH to a job's sections accepted a list of any length. A single request
with a large body blocked the event loop, so everything else waited on it,
including the progress stream a running job depends on. Measured against a
local server, an idle health check went from 32 ms to 5219 ms behind a 33 MB
body. The stall grew linearly with the body, bounded only by what the sender
was willing to upload.

Two things made it worse than a slow endpoint. It needed no valid job, because
the body is parsed before the handler runs and only then answers 404. And with
a real job it was permanent rather than transient: the list was written to
metadata.json and held in the registry, which is re-serialised on every
persist.

There are two bounds now, because one of them alone does not work.

The model caps the list at 10000. Both normalize_sections and the timeline
editor refuse a section shorter than half a second, so the longest track
StemDeck accepts cannot legitimately carry more than 7200. This is what stops a
huge list being stored.

That cap does not stop the stall. FastAPI reads and validates a request body
before the handler runs, so a model constraint bounds what is kept and not what
is parsed: with the cap alone the stall was still 5219 ms. Content-Length is
therefore checked in middleware, which is the last point that runs before the
body is touched, and the same shape as the upload pre-check already in
app/api/jobs.py. Health latency under the same attack is 16 ms.

The ceiling is 4 MB, far above either editor's reach: 10000 sections at the
longest permitted name is about 1.6 MB and 20000 beats about 0.4 MB. It covers
the beat grid too, which had the same flaw in milder form at 922 ms, and leaves
uploads alone on their own path and their own 400 MB limit.

Closes #481